The Atari Compendium

home *** CD-ROM | disk | FTP | other *** search

/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / prgtools / langs / c68_445b.zoo / man / c68.1 next >

Wrap

Text File | 1995-02-01 | 47.0 KB | 1,312 lines

C68(1) USER COMMANDS C68(1) NAME c386/c68 - Compile pre-processed C source. SYNOPSIS c386 [options] [input_file [output_file [listing_file]]] c68 [options] [input_file [output_file [listing_file]]] DESCRIPTION The c386/c68 programs are publicly available C compilers. c386/c68 support all language features defined in the original Kernighan and Richie (K&R) definition and additionally most of the extra features that have since been defined by ANSI. The user can select K&R mode (which causes many ANSI specific features to be disabled) or ANSI mode at run-time. The default is ANSI compatibility mode as this is the mode that most people would wish to use. The compiler currently exists in two major variants - one known as c68 which produces 68000 code and the other known as c386 which produces 386 code (as used on top-end PC's). The compilers were originally developed to run on the MINIX operating system, but are known to be in wide use on other systems. c386/c68 take the output of a C pre-processor, and compile it to give assembler source. If no output file is specified on the command line then c386/c68 writes the generated assembler code to standard output. If in addition there is no input file specified then c386/c68 reads the C source from standard input. Finally if a run time option requesting a listing is used and no listing file is specified, c68/c386 writes it to standard error. The options available to control the behaviour of c386/c68 are listed below. The options to c386/c68 can also be passed as -Qoption. This is to make it easier for the CC front-end program to decide which options belong to the c386/c68 program. Not all options are necessarily available in all versions of c68/c386 as some of them are dependent on the settings in the c68/c386 configuration file at the time that c68/c386 is actually built. -? Make c68/c386 display a message giving the full list of options available in this particular version of c68/c386. It also details the default settings for the parameters. This option can be very useful as it always reflects the choices of settings in the c68/c386 configuration file that were actually used when generating this version of c68/c386. -v Output additional information during the compile process. If c68/c386 was compiled without the -DVERBOSE set then this is merely a message giving the version number of the compiler. If the -DVERBOSE was used when c68/c386 was built, then additional progress information is output during the compile process. Default: c386/c68 as supplied is not normally built with the -DVERBOSE option and merely provides the version number message if -v is used. -warn=n Control the severity level of warning and diagnostic messages that will be output during the compilation process. Messages with a higher severity value (i.e. less severe) than the value specified will not be output. See later for more information on the effect of possible values for n. Default: -warn=3 -error=n Make messages that are normally only warnings to be treated as errors instead. The value of n specifies what severity of messages that would normally be only warnings are instead to be treated as errors. This option is often used in conjunction with the maxerr option.. Default: -error=0 -maxerr=n Sets the maximum error count to the value of n. This is the maximum number of errors that will be reported before c386/c68 abandons a compile. As one error can cause others to occur, in a cascade effect, it is often a good idea to set this to a low value in the region of 10-20. Default: -maxerr=200 -g Output additional information for debugging purposes. Branch optimisation is also suppressed even if the -O option has been specified. Currently this option has little other effect except to add line directives to the generated assembler output. This can still be useful if you wish to see exactly which C source lines caused particular assembler code to be generated. Default: No debugging information is generated. -O Specifies that maximum branch code optimisation is to be used. This can significantly reduce the size of the generated code with little penalty on run time. It can, however, slow down the compilation process. This option is ignored if the -g or -noopt options are specified. Default: The optimisation triggered by this option is not performed. -align ** STILL UNDER DEVELOPMENT - USE WITH CAUTION ** -noalign Align structures and unions using the same rules as applied to the member that has the strictest alignment rules. Default: -align for c386 -noalign for c68 -code Specifies whether code is to be generated, or if -nocode this run is merely being used to check for errors in the source code. The advantage of specifying the -nocode option if you are merely looking for errors is that c68/c386 will run faster if no attempt is made to generate code. Default: -code -extern This causes details of external symbols in this -noextern module to be output to the listing device. This is intended in the future to provide the basis of a lint-style facility to provide cross-module consistency checking. Default: -noextern -format Activate additional checks for the 'printf' and -noformat 'scanf' families of library routines. If active, then the parameters following the format string are checked as being compatible with the format string. Default: -format (check parameters) -fpu [c386 only] -nofpu Generate floating point code in a form suitable for direct execution by a maths co-processor if -fpu is used. If -nofpu is used instead, then calls are made instead to library support routines. This allows for software emulation of floating point to be provided (although this is not part of this release of c386). Default: -fpu -frame=n [c68 only] Specify which address register is to be used as the frame pointer. C68 will then not use for any purposes any registers with numbers larger than the frame register and less than A7. Default: -frame=6 -icode Output run-time debugging information to the listing file. Intended mainly for debugging the compiler itself. This option is only available if c386/c68 was compiled with the -DICODE option. Default: c386/c68 as supplied is not set to have this option compiled in. -lattice Older versions of Lattice C had partial support -nolattice of prototypes in which a variable number of parameters was indicated by finishing the parameter list with a comma (rather than the ANSI style of using ,...). The use of this option means the Lattice syntax will also be accepted. Default: -nolattice -list Control listing of source file being compiled -nolist (the pre-processor output!). Any listing will be put into the listing file. Any error or warning messages are included at the appropriate point in the listing. Default: -nolist -longdouble If active, then 'long double' is treated as -nolongdouble being a distinct type from 'double' with different support routines. Default: -nolongdouble NOTE: The support routines for 'long double' are not currently available for use with c386/c68. This routine is included for future compatibility. -obsolete Specifies whether warnings should be generated -noobsolete if you use an option that is currently part of the ANSI C standard, but which the ANSI committee have warned may be removed from future versions of the ANSI C standard. Examples of this is support for K&R style function definitions. Default: -noobsolete (no warnings) -opt Control the operation of the peephole optimiser. -noopt Normally the peephole optimiser is used to produce more efficient code. If you wish to suppress it you can specify the -noopt option. You would not normally use this option unless you suspect an error in the peephole optimiser. Using the -noopt option will override the -O option if it is also specified. Default: -opt -packenum ** STILL UNDER DEVELOPMENT - USE WITH CAUTION ** -nopackenum Use the smallest integer type that is capable of containing all the enumeration values that are defined for a particular enumeration type. If -nopackenum is in effect then 'int' is used as the enumeration type. Default: -nopackenum -probe Generate stack probes? These are needed if using -noprobe the compiler in a multi-tasking environment and with a 68000. The problem is that not enough information is saved on the stack for a restart of an instruction, and stack probes insure that the stack has enough allocated memory to accomidate the needs of the routine. Things like this are used on such computers as the Tandy 6000/TRS-80 16[ab] and some *other 68000 based unix boxes. Default: -noprobe Note: c386/c68 as supplied is not set to have this option compiled in. -reg Control whether c386/c68 can allocate variables -noreg to registers. Normally c386/c68 will try to do automatic allocation of variables to registers according to their run-time usage. The -noreg option forces the use of register variables only when explicitly requested by the programmer. Default: -reg -revbit Control the order in which c386/c68 allocate the bits in a bitfield. The -revbit option causes the bitfield to be allocated starting from the highest number bit downwards, rather than the default of allocating them from bit 0 upwards. Default: bitfields start at bit 0 -separate Used to force c386/c68 to allocate strings and -noseparate constants in the data segment. Unless -separate is used they are allocated in the same segment as the generated code. Default: -noseparate -short Control the length of int declarations as either -noshort 16 or 32 bit. There is a lot of code around that assumes sizeof(int)==sizeof(char *), so use 16 bit ints with care. Default: c386: -noshort c68: -short (MINIX/TOS systems) -noshort (QDOS/SMS systems) -stackcheck Used to specify that calls should be made -nostackcheck to a support routine to perform stack checks at the start of each function. To use this option, it is necessary to have implemented the appropriate (system dependent) support routine. Default: -nostackcheck -stackopt Used to control whether the 'lazy stack -nostackopt updating' optimisation is to be used. See later in the discussion on optimisation for the implications. Default: -nostackopt -trace Output run-time trace information. Intended in the future to help support a source code debugger. However, at the moment this capability is incomplete. This option is only available if c386/c68 was compiled with the -DTRACE option. Default: c386/c68 as supplied is not set to have this option compiled in. -trad Make the compiler reject most of the ANSI extensions to the original K&R definition. For more detail on what ANSI options are not supported when this option is set, see the section later in this document on K&R Compatibility Mode. Default: ANSI compatibility mode is used. -trans Make certain all names in the assembler output are only 8 characters in length (a special algorithm is used for names that are longer than this). This is used if the assembler phase cannot handle long C names. Default: c386/c68 as supplied is not set to have this option compiled in. -trap [TOS c68 only] -notrap Generate trap instructions for OS calls gemdos(), xbios() and bios(). This is not only faster but also implies somewhat shorter code. Default: -notrap -uchar Specifies that the char data type is considered -nouchar as an unsigned integer type. Normally it is treated as a signed integer type with the range +127 to -128. Default: -nouchar (signed char) It is possible to generate versions of c68/c386 that have a support for cross-compilation or alternative assemblers. If these options were specified when building c68/c386 then the following additional run-time options will be available: -ack68k Generate 68000 code. Use the ACK assembler syntax for the output. -jas68k Generate 68000 code. Use the JAS assembler syntax (of SozobonX) for the output. -cpm68k Generate 68000 code. Use the CPM 68000 assembler syntax for the output. -gas68K Generate 68000 code. Use the GNU assembler syntax for the output. -bas396 Generate 386 code. Use the sytax for Bruce Evan's 386 assembler for the output. -gas386 Generate 386 code. Use the GNU 386 assembler syntax for the output. -sysv386 Generate 386 code. Use the Unix SVR4 assembler syntax for the output. EXIT CODES The c386/c68 program returns the following error codes: 0 The compilation was successful. That is the source file was compiled, and there were no fatal errors. 1 One or more fatal compilation errors were reported. 2 The source file was not found. EXPLOITING COMPILER OPTIMISATIONS This section discusses the optimisation methods used within the compiler and how you can code to exploit these to maximum advantage. The philosophy that was used when developing the compiler was to try and strike a good balance between the efficiency of the optimisations that are done and the code/runtime penalties of doing the opimisations in the first place. The decision was made to limit the optimisations that are will be done to those that can be done by pure static analysis of the generated code. More complex methods of optimistion have been avoided. The result has been a family of compilers that produce suprisingly good code without too much penalty in the runtime size or performance of the compilers. To understand some of the following sections, you have to realise that the code generation of the compiler happens in two basic stages: a) Generic code is generated that will work under all situations. No consideration is given at this stage as to whether the particular values of operands mean that shorter variants of instructions could be used. At this stage the following optimisations are performed: - Allocating variables to registers - Removing redundant stack upates. b) The peephole optimiser is invoked that looks at the generated code to see how it can be improved. The optimisations that occur at this stage are: - Choosing optimum code sequences. - Commoning up repeated code sequences - Eliminating redundant or unecessary code. The programmer can often increase the effectiveness of these optimisation processes by writing code aprropriately. Allocating Variables to Registers The compiler will try and optimise the use of registers. You can stop this automatic allocation of variables to register by using the -noreg runtime option to the compiler. The compiler first allocates any variables for which the programmer has explicitly used the keyword register, and then (assuming there are still free registers) allocates further variables to registers using an algorithm that looks at how frequently they are referenced in the source program. This algorithm considers variables as suitable for holding in registers if they are referenced enough times so that the overhead of loading them into registers is less than the gains in code generation size of having them in registers. This results in the following tips: a) Avoid using the register keyword unnecessarily. The built in algorithms for allocating variables to registers are very good, and often will achieve better results than the programmer. b) Consider assigning variables used in loops explicitly with the register keyword. Because only static analysis techniques are used, the compiler optimises for space, and may not realise the run time performance advantage of keeping loop variables in registers (albeit possibly at the cost of increasing code size). Removing Redundant Stack Updates "Lazy stack updates" If there are several calls to functions without any intervening transfers of control, then the compiler can accumulate the stack tidying operations normally performed after such calls and do them all at as late a stage as possible. This means that multiple small stack adjustments can be replaced by a single larger one (or even sometimes not do it at all if the end of a function is reached first). This optimisation results therefore in both size and speed gains. This optimisation would, however, cause problems on any assembler routine that directly manipulates the stack. It is therefore automatically suppressed for calls to alloca() or for any routine whose name begins with an underscore. As the effects of this optimisation going wrong are extremely hard to track down, this option is only activated if explicitly requested by using the -stackopt runtime option to the compiler. Choosing Optimum Code Sequences This optimisation is simply a case of examining the code generated looking for common code sequences that can be replace by faster and/or shorter ones. This level of optimisation can be disabled by using the -noopt keyword. However, there is normally litte to gain by disabling this optimisation unless you suspect an error as it has little detrimental effect on compilation speed. Commoning up repeated code sequences The compiler will attempt to common up repeated sequences of code within a function. This can result in significant reduction in code size. However, as this optimisation can impose a significant time penalty on the compilation process, it is only invoked if the -O runtime option is supplied to the compiler. To maximise the potential gains that will be achieved by this optimisation the following tips may be useful: a) Try and ensure that the code sequences leading up to return statements or break statements within a switch construct are the same. This will allow the compiler to only generate the code once and implement all repeated occurences of such code as simple branches to the first one. b) If you have such sequences that simply dffer by one variable, then it may be worth assigning that variable to a temporary one and using that if as a result a larger sequence of code is common. Removing Redundant or Unrefereced Code This optimisation is done only if the -O runtime option to the compiler was used. It looks for any code sequence that cannot be reached. If the code in question was a direct result of the way the programmer wrote the source code then, if leve 4 warnings are active, appropriate warning messages will be output. However, this situation can also arise as result of the effects of previous stages in the optimisation process. ERROR AND WARNING LEVELS The errors and warnings within c386/c68 are classified into various severity levels. The higher the level, the more pedantic the level of messages that are output. By default all messages with severity 0 are errors, and all those with higher levels are merely warnings. The -warn and -error parameter options allow the user to vary the default treatment of these levels. c386/c68 is supplied with warning level 3 set as the default warning level (if not changed via the command line or in an environment variable). It is good practice to try and write code that compiles without warnings even at levels 4 or 5. There are then less likely to be subtle bugs lurking in your code that are coding mistakes that are difficult to spot. The levels currently supported are as follows: 0 Messages at this level are always errors. If you specify this as a warning level, then effectively all warning messages are disabled. 1 These are severe warnings that should not normally be suppressed. They typically relate to problems at the code generation stage of the compiler. 2 These relate to problems with the code that normally indicate problems or potential problems. They are typically easy to fix - normally by adding a cast or something similar. 3 This level relates to warnings that are commonly encountered when porting code. The warnings at this level may not indicate an error, but they should certainly be checked out. 4 This level of warning indicates problems that are often encountered in porting, but that are probably not an error. It is still a good idea to get your own code to compile cleanly at this level of warning as it will minimise problems later. 5. This level of warning is for short cuts that experienced C programmers often use, but that are occasionally done in error. You are most likely to find this level useful when trying to track down an error that you are having trouble locating. It is good practice to write code that is warning free even at this level. 6 This is the most pedantic level. It will only be useful to those who are looking for very awkward porting problems. A detailed list of the error and warning messages that can be output is given later. ENVIRONMENT VARIABLES The Environment Variables C386 or C68 (as appropriate) are checked to see if they are present, and if so are assumed to contain options in the same format as the command line options. This is done before processing the command line. Command line options will therefore over-ride the Environment variable settings in the event of conflict. The Environment Variable method is a very convenient way of setting defaults such as the warning level. ANSI FEATURES NOT SUPPORTED The following features specified in the ANSI standard are NOT supported - Trigraphs. It is possible, however, that you have a pre-processor that handles trigraphs, in which case this is done there rather than in the c386/c68 program. - Multi-Byte and wide characters are not fully supported. The syntax is accepted, but treated as if of type char. CHANGES TO FEATURES IN K&R COMPATIBILITY MODE If K&R compatibility mode is specified by using the -trad run-time option, then the following changes occur in the features supported by c68/c386: - The long double qualifier is not allowed. - The use of the long float qualifier as a synonym for double is permitted. - The const keyword is not allowed. - The volatile keyword is not allowed. - The signed keyword is not allowed. - String concatenation is not performed. - Single copies of identical strings are not generated. Instead separate copies will be generated every time a string is used. - ANSI style function prototypes are not allowed. - ANSI style function declarations are not allowed. ERROR AND WARNING MESSAGES The following is a list of the error messages that can be output by the compiler. In most cases the messages are self-explanatory, but where this is not so, additional information is given about the possible cause of the error message. Where variable information can be inserted into the message, then this has been specified using the printf format string method. LEVEL 0 This level of message is always an error. It is not possible to make c68/c386 treat such messages merely as warnings. "& operator may not be applied to bitfields" "& operator on register variable '%s'" The ANSI standard does not allow the & operator to be used on variables that have been qualified with the register keyword. "{ expected on initializer" If you are initialising a complex structure such as an array or structure, then the initialisation values should be enclosed in braces. "an object type expected" "arithmetic type expected" "attempt to modify 'const' value" "break not allowed here" "cannot nest function definition '%s()'" "cannot subtract a pointer from an integral value" "case not allowed here" "character constant unterminated or too long" "constant expression expected" "constant expression exceeds representable range" "constant integer expression expected" "continue not allowed here" "declared argument '%s' missing" "duplicate case label 'case %ld'" "duplicate default label in case" "duplicate label '%s'" "error casting a constant" "error dereferencing a pointer" "error doing a cast" "error while scanning a parameter list" This implies that the compiler has encountered something unexpected while scanning a parameter list. It is commonly caused by a misplaced comma, or a misspelt type keyword. "expression expected" "floating point constant expected" "function body expected" "function declarator not allowed here" "function returning array type" "function type expected" "function '%s' declared but never defined" This will occur if you put a forward declaration for a function in a file, and then never define that function. It could also occur if you meant to forward declare a library function, but omitted the 'extern' storage class specifier. "function '%s()' default promotion / prototype mismatch" This is typically caused by mixing ANSI and K&R methods of function declaration and definition. This is of particular importance for functions which have parameters of types 'char', 'short' or 'float' as the parameter promotion rules for these types are different for K&R and ANSI declarations and definitions. "function '%s()' prototype mismatch" This indicates that the for the specified function, there are incompatible definitions or declarations. This can be either in the type returned, or the number or types of the parameters. "general error" This error means that a consistency check within the compiler has failed. Please report the circumstances that caused the problem, and ideally provide a sample of code that can be used to reproduce the problem. It is preferable if any code that is supplied to illustrate a problem has already been passed through the C pre-processor. This eliminates any dependencies on system specific header files. "identifier expected" "identifier list not allowed on function declaration" "illegal cast operation" "illegal character '%c'" "illegal constant integer expression" "illegal field width" "illegal floating point constant" "illegal initialization" "illegal redeclaration of '%s'" The function/variable has been declared in a way that is incompatible with an earlier use. "illegal 'sizeof' operation" "illegal storage class" "illegal type combination" "illegal unprintable character (value=0x%x)" "implicit conversion to pointer on register variable '%s'" "incomplete '%s' declaration" "initialization invalid" "integral type expected" "l-value required" A l-value is simply an expression which it is legal to have on the left side of an assignment expression. "no field allowed here" "parameter count incorrect for function %s" "pointer type expected" "problem with pre-processor output" This indicates that what looks like a preprocessor symbol (one starting with #) was found in the source file. This is typically caused by trying to use c68/c386 raw C source before it has gone through the C pre-processor. "qualifier already specified" This means that there are duplicate qualifiers of the same type refering to the same variable or function declaration/defintion. The second one will simply be ignored, but the source should be corrected. "return expression of type void" It is not possible to return an expression which evaluates to type void. "return value specified to void function" "scalar type expected" "string constant unterminated or too long" This message may well occur well after the point at which the string constant started. It is quite often caused by mismatched comments or #if/#endif directives. "too many initializers" The number of initializer values would exceed the size of the variable space allocated to hold them. "type already specified" "type mismatch error" "type/operand has unknown size" "undefined identifier '%s'" "undefined label '%s'" "unexpected end of file" This is typically caused by a mismatch between the number of start and close braces. "unexpected symbol '%s' found" This simply means that the symbol shown was not legal at this point, and the compiler has been unable to specify the error more accurately. "value of escape sequence out of valid range" "void parameter is passed to function %s" "'%s' cannot be used as a label here" "'%s' is not a struct/union member" "'{' expected on initializer" LEVEL 1 This level of message is used to indicate code that although allowed by C is extremely bad coding practice, and as a result is normally not what the programmer meant. "bit field type should be unsigned or int" "#pragma ignored", The #pragma directive has no special use within the c68/c386 compiler. Any lines that contain this directive are therefore simply ignored. LEVEL 2 This level of warning is used to indicate code that may well not be an error. However, experience has shown that in reality the code does not perform the action that was intended. "attempt to allocate zero storage", The data item specified is of zero size. "auto initialisation not reached" "conversion between incompatible types" This message indicates that the two types in question are not defined by the C standard to be compatible. If you really mean the statement, then the message can be suppressed by use of a suitable cast. "redefinition of '%s'" "'sizeof' value is zero" "'sizeof' value %d is greater than '65535'" This will occur when the size of a sizeof operator is set to be only 16 bits, and the result of a sizeof operator is larger than 16 bits. The data type returned by the sizeof operator is in fact determined by the value defined for TP_SIZE in the configuration file (config.h) used when c386/c68 was compiled. It is important that this value should agree with the value defined for size_t in your system include files. "\x not followed by any hex characters" The \x sequence that ANSI specifies as being used as an escape sequence to introduce a hex character was not followed by values that could be interpreted as hex. LEVEL 3 This level of message indicates code that is probably not an error, but is untidy. Messages in this category can normally be suppressed by making simple modifications to the source code. "a cast from short to pointer is dangerous" There is very rarely much point in storing a 16 bit short value in a pointer which is 32 bits in size as it is virtually guaranteed to not be what you meant to do. "conversion between incompatible pointer types" Very common message when a pointer of one type is assigned to a pointer of a different type. Inserting the relevant cast will suppress this message. "dubious %s declaration; use tag only" This normally means that a structure or union pointer has been encountered using a tag which has not been defined. "escape ignored in sequence '\%c'" The character following the \ is not one that is supported as a valid escape sequence. "function '%s' declared but never defined" This normally means that there is a forward declaration for a static function, but that the code defining that function is not present. "implicitly declared function: 'int %s()'" This means that there is no declaration (either ANSI or K&R) in scope for this function. If the function is a standard library function, then it means that the relevant header file has not been included. "no value specified in 'return' statement" This occurs when a return statement is found for a function that has an implicit int type. It can be suppressed by defining the function to be of type void. "qualifier inconsistent with type 'void'" This implies a const or volatile qualifier used in conjunction with a void type. LEVEL 4 Messages at this level are not strictly speaking errors, but they do indicate code that could be improved. In particular, they indicate code that might have portability problems. "argument '%s' implicitly declared 'int'" This means that an argument to a function has been specified which has not been explicitly given a type. It has therefore been treated as an int. Declaring the argument type explicitly will stop this message being generated. "definition of '%s' hides an earlier definition" This occurs when a variable name is used in an inner block that has the same name as one that has a wider scope. It is just a warning that during the duration of the block the variable at the outer level will be inaccessible. The commonest cause is when the name of a parameter to a function is the same as that used for a global variable. NOTE: Due to the way that the compiler works, you can also get this warning if you include a variable name (which is not strictly speaking required) in a function prototype. "empty statement" An empty statement has been found following a construct like an if or while statement. There are situations in which this is exactly what the programmer meant, but it might also be due to an accidental semicolon being present. "extern definition '%s()' redecalred static" "implicit cast of const pointer to pointer" "K&R style function" This message will only be output if the -obsolete runtime option to the compiler has been used. It is a warning that in the future that support for K&R style function definitions may be removed from the ANSI C standard. "no type specifier - add 'int'" This indicates that a variable has been encountered whose type is not explicitly stated. It will be defaulted to 'int' but it is much better style to put this in explicitly. "parameter %d to function %s() promoted to '%s'" This means that the size of a parameter was changed according to K&R promotion rules. This message can be suppressed by having an ANSI style prototype of function definition in scope, or by using an explicit cast. "size of parameter %d changed by prototype on function %s" This implies that an implicit cast was applied as a result of a prototype being in scope. Care would need to be taken when porting such code to an environment which does not have an ANSI compatible C compiler. It is often a good idea to add an explicit cast to such calls as this at least makes it clear what is happening, and will make code more portable. "statement not reached" This message means that the statment in question is preceded by a construct that means program flow cannot reach the statement. A typical cause might be code that follows a return statement without a label. This can quite often happen in the more subtle context of a switch statement in which all cases are terminated by return statements, but there is then code following the end of the switch statment. "storage specifier not at start of definition" The ANSI C standard has declared that a future version of the standard may require storage specifiers to be used only at the start of definitions. The current version of the ANSI C standard allows more leeway. "the use of '%s' is not allowed under strict K&R C" This is used to indicate that a construct has been used that was not part of the K&R specification, but that virtually all modern compilers support even if they do not claim to be ANSI compatible. This message will only be output if you are running in K&R compatibility mode. "zero-sized typedef may be changed by initialisations" The typedef as written will have zero size, but if used in conjunction with an initialiser it will be OK. "& operator on array ignored" The & operator was used in conjunction with an array name. This is not required as the use of an unsubscripted array name implicitly points to the first element of the array. "& operator on function ignored" The & operator was specified on a function reference. It is not required as it is implicit. "%d expression to '?:' operator cast to void" LEVEL 5 "'%s' has 'const' qualifier but is not initialised" "assignment in conditional context" This means that there was no conditional test found, so it is possible you put an assignment when you meant to put an equality test. This message can be suppressed by testing the result of an assignment against zero. "constant expression used in '%s' statement" "dangling 'else' statement" This is a warning that a construct of the form if (test) ... else if (test2) ... else has been encountered, and it is possible that the last 'else' statement is not associated with the if statement that the programmer mean. Use of braces to clarify the statement will suppress this warning. "format mistmatch with parameter %d on function %s" This message is output when checking format strings for the 'printf' and 'scanf' families of routines against the following parameters. This indicates the parameter is not of the type indicated by the format string. "ignored return value from function %s" This means that you did not use the return value from a function. Inserting a (void) cast before the function call will suppress this message. "label '%s' declared but not used" A common cause of this can be leaving the 'case' keyword of a branch of a switch statement. This can be remarkably hard to spot sometimes as the code is still syntactically correct. "no value specified in implicit 'return' statement" The end of a function definition has been reached so that there is an implicit return. The type of the function is not void so in theory there should be an explicit return statement with a value. However, much C code is written so that the type of a function is defaulted (which means it becomes int) and the return value of a function is not used. Explicitly declaring the function type as void will stop this message being output. "no prototype defined on called function %s", This occurs if the function has been earlier defined via a K&R definition, and there is no ANSI prototype in scope. "variable/function '%s' not used" There is a variable and/or function that has been declared but not used. This check is done at the end of a function/block. This means that for a variable, the line number quoted with this message is that for the start of the next function/block after the one that defines the unused variable. For a function, the line number quoted will typically correspond to the end of the source file. LEVEL 6 The warnings that occur at this level are not normally relevant to the average user. "a cast changed an integer constant (%08lx->%08lx)" This indicates that an implicit cast changed the constant as stated in such a way that significant bits may have been lost. "a cast to a narrower type loses accuracy" This is really not a problem if the action is what was intended. The purpose of this warning is to highlight situations in which there may be an implicit assumption built into the code as to the size of a field of a particular type, which may not be true on the current machine. "partially elided braces on initialisation" This rather cryptic message can be output when initialising unions, arrays and structures. The C standard says that initialisers for all such constructs should ideally have braces around them. This message therefore means that the bounds of a particular element of the data structre had to be deduced from its position in the initialisation list rather than being explicitly bounded by braces. The requirement to suppress this message is that the values for an union, array or structure must start and end with braces. In the case of more complex structures such as an array of structures there must ne braces around the whole set of values (ie the array) and also braces around the values for each occurence of the structure. "pointer difference cast to 16-bits" Pointers in c386/c68 are 32 bit values, so if the result of subtracting them is stored in a 16 bit variable then the value might be truncated. This is most likely to be a problem if you are treating 'int's as 16 bit values. In other situations it is likely that the program logic ensures that the results cannot be larger than a 16 bit value. LEVEL 7 The warnings that occur at this level are not normally relevant to the average user. They are extremly pedantic in nature and are normally onky realy relevant to tidying up the code. "initialisation incomplete - remaining fields zeroed" This message is output if the initialisation statement supplied for a data item would not initialise all elements of that item. There are often times when this is exactly what the programmer meant to do, but occasionally it is due to the initialisation being incomplete. "unnecessary cast to 'void'" This is when a void expression is explicitly cast to a void. This is a null operation, so you do not need to specify the void. CODE GENERATOR WARNINGS The following warning messages can be output by the code generator part of C68/C386. They are output regardless of the warning level specified. These messages are not intended to be of use to the average user, but are instead diagnostic messages indicating that internal consistency checks have failed. In theory the situations that cause them to be output should have been detected in the parsing stage of the compiler. They thus may well indicate a problem earlier in the compiler. If you suspect this is the case, then please submit an error report (see also the comments earlier under the "general errror" warning message). "changing integer constant on output (%08lx->%08lx)" "division by zero in constant node" This indicates that while c386/c68 was evaluating a constant expression, a division by zero has been encountered. "illegal operation in dooper %s" This indicates an internally detected error while handling the specified operation. "non-positive shift constant" "shift constant out of range" The value of the shift constant is so large that the answer will always be zero AUTHOR(s) Versions prior to release 4.0: Christoph van Wullen. ANSIfication work and other enhancements in Release 4.0 and later releases: Keith Walker email: kdw@oasis.icl.co.uk (bug fixes, IEEE support, ANSIfication) Dave Walker email: d.j.walker@slh0101.wins.icl.co.uk (IEEE support, Errors/Warnings, documentation) Port to Atari ST (TOS version): Thorsten Roskowetz email: rossi@titan.rz.uni-osnabrueck.de SEE ALSO cc68x(1), cpp(1), as68(1), ld(1)